I wouldn't go as far as the author of The Free Lunch is Over: A Fundamental Turn Toward Concurrency in Software, but (IMHO) much of the current growth in processing speeds has been the result of harnessing the parallel processing of cheap COTS computers – Google, for example. Multi-core CPUs look like a similar phenomenon.
Further thoughts: It looks to me as if concurrency is like every other development paradigm – simpler is better. To me, this means:
As an example of encapsulated concurrency, off-loading printing to another thread (from the viewpoint of the caller) is mostly a matter of handing the contents of the page off to a subroutine – no further interaction with the print routine is necessary once the data has been prepared.
From where I'm sitting, there's a significant difference between threads that must continue interacting with each other as compared to threads that each go their merry way once the threads have been created. This second case of threading, with the threads (at least mostly) independent after their creation is amenable to encapsulation – and encapsulated code (including encapsulated threaded code) is easier to deal with. We mortals are equipped to mentally deal with only a limited number of "things" at one time, so encapsulating threaded behavior is a Good Thing.
I'm just musing here, but there may also be gains to be had from letting programs perform more actions in the background, with appropriate caching of the results for later use. (The Caching and Memoization chapter in Higher-Order Perl has influenced my thinking lately.)
At least for a while, common processing power gains will come from an increased number of CPU cores rather than faster CPU cores, so we software engineers need to prepare ourselves for this phase of computing.
